Subject: re:Setting Goals and Focusing our efforts

From: "Jim (J.) Cobban" <[email-masked]>
Date: Fri, 6 Aug 1993 10:22:00 +0000

In message "Setting Goals and Focusing our efforts", 
[email-masked]' writes:

>Required Questions for Active Members:
>
>1) Do you believe that the current DLSw State Machine can be (or should
>be) modified to support all of the following (for SNA PUs this includes
>all combinations as far as the end stations being LLC or SDLC (i.e. full
>interconnectivity))?
>
>    Pu2.0
	      YES.
>    PU2.1
	      YES
>    Other PU types
	      PU 1 is probably desireable for 5250 support to AS/400s
		   and this is (for 5250s) no more difficult than PU 2.0.
	      PU 4 is clearly desireable, but is extremely risky because
	           the XID negotiation on SDLC is not documented and varies
		   from product to product.  Further as of ACF/VTAM V4 and
		   NCP V6 there is no longer a need to support PU 4.
		   However PU4-PU4 where both ends are LLC2 is
		   straightforward.
>    Support for non equal SAPs (e.g DSAP=8, SSAP=4)
	      This is essential.  Also the CANUREACH protocol seems
	      excessive for starting multiple LLCs between the same
	      pair of MACs.
>    NETBIOS
	      YES
>
>2) Does everyone agree that both NETBIOS and SNA should be supported
>by DLSw?  (ref. Jim Cobban's mail message sent Aug. 3 on only including
>SNA and excluding NETBIOS.)

   I did not exclude NETBIOS.  I excluded the UI frames of NETBIOS.
   DLS already excludes the UI frames of IP, IPX, XNS, VINES, etc. etc.
   so why should the NETBIOS UI frames be treated specially.  There is
   still ample benefit to the carriage of the LLC2 multiple acknowledgement
   protocol (SABME, I, S, DISC) portion of NETBIOS.  If we are going to
   carry the NETBIOS UI frames, then equity demands that we also carry the
   UI frames of other protocols.

>
>3) Should the current mechanisms for sending the XID and TEST frames
>be modified to not establish the DLSw circuit until SABME/UA or SNRM/UA
>phase (e.g. like Cisco's Stun Mechanism)?
>
   I am certainly not dogmatic about my proposal.  I do not believe that
   the source route explorer frames, whatever type of frame they happen to
   be, should be handled differently for two protocol stacks extracted from
   the whole set of protocol stacks which may be bridged across the IP
   subnet.  However I am willing to concede that there are advantages to
   processing all of the specifically routed frames through the DLS
   mechanism.  That would include those XIDs which are part of the
   negotiation process for establishing an SDLC link.  I feel that the
   DLS protocol would be simplified if specifically routed UI frames were
   simply carried as such, without decoding them to find out what aspect of
   the NETBIOS protocol they are handling.  That would make DLS more protocol
   independent and permit supporting other protocols for which their is
   no router stack implemented on the node.  

   I am convinced that specifically routed TEST frames should not be
   carried across the DLS connection.  They should be acknowledged locally.
   That avoids some pathological cases where the round-trip network delay
   is greater than the sender's time-out.  

>4) Should DLSw be modified to handle LLC type 2 connections for protocols
>other than SNA or NETBIOS (i.e. generic LLC type 2 support)?
>
   Our European customers are very interested in X.25 over LLC2 (ISO 8881).
   If the source-route discovery process is separated from DLS then
   support of generic LLC 2 is straightforward.

   As far as I am aware those three protocols are the only users of LLC 2.
   I would be very much interested if anyone could let me know of other
   protocol stacks that future customers might surprize us with.

-------------------------------------------------------------------------------
Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars5!jcobban         |  FAX:   (613) 763-2626

---

From: [email-masked] (David Matusow)
Date: Fri, 6 Aug 93 13:24:00 -0400

>       Support for non equal SAPs (e.g DSAP=8, SSAP=4)

I think that the best way to proceed is to pick a subset to support
in the current implementation and then proceed with extending the
architecture, understanding that we WILL want to expand.  We don't
have to answer HOW we are to support others...only that we will and
be cognizant that we don't box ourselves into a corner.

non-equal SAPS needs to be handled because of the method of establishing
a TCP session and multiple connections between DLS switches.

PU20 and PU21 should be handled here.  It is best to leave DLS out
of XID exchange (we stay transparent to the exchange and only pick
pieces out as it passes through (maximum packets, max. packet size,
etc.)).

netbios LLC2 should be handled.  It might make sense to only bridge
the LLC1/UI packets.  This allows the data to pass, but DLS to not
be involved.

>   SNA and excluding NETBIOS.)

his response today and above reflect our feelings on this.

>   phase (e.g. like Cisco's Stun Mechanism)?

By delaying, we gain (possibly!?) some sessions.  This would be true
if we drop certain sessions while waiting for XIDs to be passed between
nodes.  I don't know if this is valid, but at a gut-level, it seems
a better path.

>   other than SNA or NETBIOS (i.e. generic LLC type 2 support)?

later.  let's get something up before we extend to the "world"

>   If you have any other questions or suggested goals please submit them
>   to the group ASAP.  Lets just have basic questions or goals only please.
>   We can haggle over protocol specifics once an agreement on goals 
>   is reached by the group.  All input is welcome!
>   

I believe it was Shannon that brought up the buffering question.
This has been one of our most nagging concern about DLS from the 
start.  If we are a router in the middle of a large network,
we could be required to handle an exordinant amount of buffering
for the TCP sessions; this figure could easily be in the megabytes,
most likely in the 10's or 100's.  I don't think ANY of us feel that
this is appropriate.

>   The specification will have to include:
>   
>           A complete state machine (including all events in/out and timers)
>           Full documentation of any implementation options.
>           Full documentation on all events (frames, timeouts, conditions).
>           Flow diagrams of all "normal" protocol flows.
>           Flow diagrams of "typical" error path flows (e.g. line loss).
>           Options in the protocol clearly documented as such.

STRONGLY AGREE WITH THIS LIST.  These should be MINIMUM requirements!
(though I can't give you more, I'm sure that we will go beyond this
list.)

David Matusow
Hypercom

---

From: "almost, but not quite, entirely unlike tea 09-Aug-1993 0903 -0400" <[email-masked]>
Date: Mon, 9 Aug 93 09:02:19 EDT

; Required Questions for Active Members:
; 
; 1) Do you believe that the current DLSw State Machine can be (or should
; be) modified to support all of the following (for SNA PUs this includes
; all combinations as far as the end stations being LLC or SDLC (i.e. full
; interconnectivity))?
; 

First let me state that it seems to me that little or no modification is 
required to the protocol or FSMs to support the following - it's more a matter
of documenting how than inventing new protocol - of course there might be 
_better_ ways of supporting these, but that's not the goal is it?

;     Pu2.0

Yes

;     PU2.1

Yes

;     Other PU types

Less important, but again I think it falls out of describing how to support
SDLC-to-SDLC, at least in the simple case. Of course there will be 
implementation specifics around mapping SSP to FID4 SDLC, but I don't see
that it need affect the SSP definition.

;     Support for non equal SAPs (e.g DSAP=8, SSAP=4)

Yes - isn't this just a matter of taking out the line in the spec that says
"SSAP=DSAP" ;-)

;     NETBIOS

This is not of direct interest to me.

; 2) Does everyone agree that both NETBIOS and SNA should be supported
; by DLSw?  (ref. Jim Cobban's mail message sent Aug. 3 on only including
; SNA and excluding NETBIOS.)

I think we should stick to SNA for the moment at least.

; 3) Should the current mechanisms for sending the XID and TEST frames
; be modified to not establish the DLSw circuit until SABME/UA or SNRM/UA
; phase (e.g. like Cisco's Stun Mechanism)?

I'm not convinced it makes a huge difference, and in general my preference
would be to minmimise changes to the current SSP definition.

; 4) Should DLSw be modified to handle LLC type 2 connections for protocols
; other than SNA or NETBIOS (i.e. generic LLC type 2 support)?

As above - let's stick to SNA for the moment!

Simon Graham
DEC

---

From: [email-masked]
Date: 11 Aug 93 10:10 EST

-

    Pu2.0

    PU2.1

    Other PU types

          >> Not Right Now

           Support for non equal SAPs (e.g DSAP=8,
          SSAP=4) NETBIOS

          >> ABSOLUTELY!!! I have seen as much, if not more, interest
          >> from customers in the NetBIOS aspects of DLSw as I have
          >> with the SNA elements.

           3) Should the current mechanisms for sending the
          XID and TEST frames be modified to not establish the DLSw
          circuit until SABME/UA or SNRM/UA phase (e.g. like Cisco's
          Stun Mechanism)?

          >> I don't believe this is a priority.

          >> A nice to have, again, not a priority with me.

          Bill Donovan
          Proteon

I believe that we all would like to have a standard that we can all
agree on and work together on documenting.  But we must have discussions
that are productive.  No protocol is perfect, so lets not try and build
a perfect protocol.

Once we agree on goals then I have some sugestions on how to proceed with
the actual work.

We want a protocol that works for all cases we decide to do, and that is
documented well enough so that all companies can implement it.
All of us are very familiar with other "standards" documents that are not
clear and this only leads to interoperability problems.
The specification will have to include:

Remember folks, this is your group.  If you want it to succeed then
it will take more work than just reading the mail.  If all we have are
readers, then there will be nothing to read and no work accomplished.
My job as chair will be to keep the group focused and working as a team.

>From this point forward I will start setting some deadlines,as appropriate, in

I believe the questions above will be easy to respond to, so please
get your answers in ASAP.

Thank you,
Alan K. Bartky ([email-masked])
Sync Research Inc.
Chair Connect/Disconnect Working Group